Продолжаем рассказывать о решении для создания отказоустойчивой инфраструктуры хранения виртуальных машин для платформы Hyper-V - StarWind Native SAN. Недавно, кстати, мы писали о том, что появилось бесплатное издание StarWind Native SAN for Hyper-V Free edition с функциями отказоустойчивости хранилищ хост-серверов.

На этот раз предлагаем вашему вниманию документ "Virtualization Reality: Why StarWind Virtual SAN Solutions Deliver Value When Compared to Microsoft", в котором рассмотрены 5 причин, исходя из которых решение StarWind Native SAN имеет преимущества и ценность по сравнению со встроенными средствами Microsoft Hyper-V, такими как Shared Nothing Live Migration, Hyper-V Replica и механизмом кластеризации через SMB 3.0.

Также в документе, помимо всего прочего, рассмотрены архитектуры Scale-Out File Servers, о которой мы уже писали вот тут, и построение кластеров Microsoft на базе дисковых полок SAS JBOD. Как не трудно догадаться, все это хуже, чем решение StarWind Native SAN.

Очень давно мы писали про тип виртуальных дисков Paravirtual SCSI (PVSCSI), который появился в VMware vSphere 4 и был создан для требовательных к ресурсам ввода-вывода нагрузок. На заре своего развития виртуальные диски типа PVSCSI не рекомендовались к использованию в качестве загрузочных, а также имели несколько серьезных багов, но широко тестировались в связи с тем, что показывали большую производительность, чем стандартный LSI SCSI.

Эту статью мы пишем, главным образом, здесь для того, чтобы сказать - уже можно. Виртуальные диски Paravirtual SCSI достаточно стабильно работают в VMware vSphere. В KB 1010398 мы видим матрицу поддержки дисков pvscsi для различных релизов VMware vSphere (обычные и boot-диски):

В VMware vSphere/ESXi 5.1 поддерживается все то, что поддерживалось и в предыдущих версиях платформы.

Что же раньше были за баги с PVSCSI? Смотрим, например, в статье тут, отсылающей нас к KB компании Microsoft. Ошибка существовала для ОС Windows Server 2008 R2 и была критической, а устранена была только в VMware vSphere 5.0 Update 1, о чем есть KB 2004578.

Теперь о том, как поставить диск типа PVSCSI в качестве загрузочного для виртуальной машины на ESXi. Выбираем в vSphere Client контроллер типа VMware Paravirtual :

В настройках виртуальной машины добавляем виртуальный floppy-дисковод и указываем образ дискеты с драйвером PVSCSI, который лежит в папке vmimages->floppies (если там ничего нет, идем сюда):

Дальше при выборе диск для установки Windows указываем драйвер с дискеты:

Дальше ставим все как обычно. Если хочется запихнуть драйвер PVSCSI в кастомизированную ISO-шку, то вам сюда. И да, драйвер на образе дискеты от Windows Server 2008 прекрасно работает на Windows Server 2012, который, в свою очередь, работает на VMware vSphere 5.1.

Компания StarWind Software, производящая продукт номер 1 для создания отказоустойчивых хранилищ StarWind iSCSI SAN & NAS, приглашает на бесплатный вебинар "Increase Operational Efficiency with StarWind!", который проводит Анатолий Вильчинский, системный инженер StarWind Software.

На вебинаре будет рассказано о том, как с помощью решений StarWind можно улучшить эффективность хранения данных виртуальных серверов за счет функций дедупликации, а также функций высокой доступности хранилищ (напомним, что использовать их можно бесплатно).

Вебинар состоится в четверг, 24 января в 19-00 по московскому времени. Регистрируйтесь!

Полгода назад мы писали об особенностях работы технологии VMware Storage vMotion, где касались максимального числа одновременных миграций SVMotion на хранилище VMware vSphere. Там же мы вскользь касались миграций vMotion и упоминали вот эту нашу статью, где рассматривались лимиты одновременных миграций vMotion на серверах и хранилищах.

Теперь, на основе статьи Франка, мы обобщим и актуализуем информацию по миграциям vMotion и Storage vMotion в разных контекстах - на уровне хранилищ, сети и хост-серверов VMware ESX.

Как и в прошлой статье, здесь будем пользоваться понятием стоимости миграции в единицах (cost) и максимального значения костов в тех же единицах (max cost), которое отображает предельно допустимое значение. Сумма костов операций vMotion и SVMotion не должна превышать max cost для соответствующего объекта (datastore, NIC и хост ESXi).

Теперь взглянем на таблички (в них есть не только vMotion, но и SVMotion):

Хост ESXi

Сеть

Хранилище (Datastore)

Читать эти таблички просто - например, для хоста ESXi стоимость миграции vMotion равна 1, а поскольку max cost равно 8, то всего на хост может быть 8 одновременных миграций в конфигурации по умолчанию. Либо допустимы одновременно: 1 миграция SVMotion (4 очка) и 4 штуки vMotion (по одному очку каждая), т.е. суммировать надо по костам: 4+1+1+1+1=8.

Для хранилища (Datastore) также есть ограничения vMotion, поскольку передаются страницы файла подкачки (если он не шаренный между хостами), а также производится передача владения VMX-файлом и другими файлами ВМ на хранилище. Но поскольку влияние это мало, то стоимость vMotion для хранилища всего 1 при максимальной емкости одновременных операций 128 (а вот SVMotion, требующая значительных ресурсов хранилища, "кушает" 16 единиц). Таким образом 1 операция vMotion съест 1 единицу коста, поэтому в этот момент для хранилища будет доступно только 7 миграций SVMotion, т.е. (128-1) div 16 = 7.

Соответственно, редактирование параметра Config Key для соответствующей операции позволяет изменять количество одновременных операций vMotion/SVMotion. Для редактирования параметра Config Key нужно отредактировать конфигурационный файл vpxd.cfg на сервере VMware vCenter, который находится в папке:

%ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter\

Там нужно вписать новое значение в соответствующую секцию. Например, для параметра maxCostPerEsx41Ds:

< config >
< vpxd >
< ResourceManager >
< MaxCostPerEsx41DS > new value < /MaxCostPerEsx41DS >
< /ResourceManager >
< /vpxd >
< /config >

Если соответствующей секции нет, то ее можно просто добавить. Уменьшать максимальные косты точно можно, а увеличение работает не всегда. То есть гарантированно вы сможете только уменьшить число одновременных миграций vMotion или SVMotion, а вот увеличить - не факт. Ограничение можно делать двумя способами - повышением обычных костов или понижением максимальных костов.

Теперь самое интересное - это динамический параметр max cost для сетевых адаптеров. Как видно из таблицы, его действующее значение зависит от типа сетевого адаптера на хосте - 1G или 10G. Но, на самом деле, и не только от типа. Точнее - от скорости соединения для трафика vMotion между хостами ESXi, которую обнаруживает VMkernel. Таким образом:

• Если VMkernel обнаруживает соединение на скорости 1Gbit/s - Maximum Cost выставляется в значение 4 (это верно и для случая соединения 1G<->10G).
• Если VMkernel обнаруживает соединение на скорости 10Gbit/s - Maximum Cost выставляется в значение 8.
• Если VMkernel обнаруживает соединение на скорости ниже 1Gbit/s - Maximum Cost выставляется в значение 2.

Таким образом, для адаптера возможны либо 2, либо 4, либо 8 одновременных миграций vMotion, в зависимости от действующей скорости соединения. Операция Storage vMotion, как видно из таблицы, костов сети не кушает.

Если ограничение для сети жестче (например, 4 миграции vMotion), чем ограничение для хоста (8 миграций vMotion) - то для машин этого хоста действует ограничение сети.

В этой части статьи разберем рекомендации по настройке взаимодействия физических клиентских устройств и виртуальных десктопов. С точки зрения информационной безопасности это важные ограничения, т.к. влияет явно на возможную передачу конфиденциальной информации между физическими клиентскими устройствами и виртуальными десктопами. Глобально пользователи должны использовать виртуальные десктопы в удаленном режиме (Remote Mode, Online). Т.е. физически виртуальные десктопы должны находиться на серверах, а не клиентских устройствах пользователей...

В прошлой статье про средство резервного копирования и восстановления StarWind Hyper-V Backup Plug-in (опция к StarWind Native SAN for Hyper-V) мы обещали рассказать про такие режимы восстановления как:

• Restore in Sandbox - возможность восстановить ВМ без ее влияния на продуктивную работающую копию (восстановление происходит в изолированное виртуальное окружение)
• Restore from archive - возможность восстановить ВМ напрямую из архива (в случае крайней необходимости)

Restore in Sandbox

Этот режим нужен тогда, когда требуется восстановить ВМ в изолированное окружение и что-нибудь проверить, например, что все данные внутри остались целостными и приложения работают (т.е. архив пригоден для восстановления). Для этого нужно выбрать пункт "Restore in Sandbox" для резервной копии:

Восстановленная и запущенная виртуальная машина будет полностью изолирована от работающей продуктивной копии за счет собственных настроек сетевого взаимодействия и отдельного хранилища.

Вот так это выглядит в консоли Hyper-V Manager:

Restore from archive

Этот режим можно использовать только в экстренных случаях, когда виртуальная машина должна быть восстановлена безотлагательно. Для этого нужно выбрать пункт "Launch VM from Archive" из контекстного меню хранимой резервной копии.

После этого будет выдано предупреждение:

Чекбокс перед восстановлением заставляют поставить потому, что такой тип восстановления приведет к тому, что все инкременты данной резервной копии будут потеряны (т.е. останется только полная резервная копия последнего состояния), поскольку нужно запустить виртуальную машину, используя образ ВМ из архива.

Поэтому, если есть возможность, следует использовать варианты восстановления "Restore Original VM" или "Restore in Sandbox"

Напомним также, что у StarWind есть плагин для резервного копирования виртуальных машин и на платформе VMware vSphere - VMware Backup Plug-in.

На днях компания VMware провела целых два тестирования (тут и тут), целью которых было сравнение производительности виртуальных дисков VMDK и RDM виртуальных машин на платформе VMware vSphere 5.1. Напомним про предыдущие сравнения VMFS и RDM, где основной моралью был тот факт, что оба этих типа виртуальных дисков практически идентичны по производительности, поэтому их следует использовать только в случаях, когда требуется специфическая функциональность (например, кластеры MSCS и большие диски для RDM):

• ESX 3.0.1
• ESX 3.5

Итак, для первого тестирования использовалась следующая конфигурация:

В качестве нагрузки использовался тест DVD Store для приложения, симулирующего интернет-магазин на платформе mySQL 5.5. Также было задействовано несколько тестовых клиентов для создания реальной нагрузки.

Масштабируемость производительности под нагрузкой (OPM - это orders per minute):

Как видно из результатов, масштабируемость производительности при увеличении числа ВМ почти линейная, а результаты различных типов дисков - идентичны (на самом деле, VMDK показал себя на 1 процент быстрее RDM для 1-й ВМ и чуть медленнее для 4-х ВМ):

Затраты ресурсов CPU на обслуживание операций ввода-вывода также чуть-чуть (на тот же 1%) лучше в пользу VMDK:

Теперь обратимся ко второму исследованию. Там использовалась следующая тестовая конфигурация, выдающая 1 миллион IOPS на тестах:

Hypervisor: vSphere 5.1
Server: HP DL380 Gen8
CPU: Two Intel Xeon E5-2690, HyperThreading disabled
Memory: 256GB
HBAs: Five QLogic QLE2562
Storage: One Violin Memory 6616 Flash Memory Array
VM: Windows Server 2008 R2, 8 vCPUs and 48GB.
Iometer Configuration: Random, 4KB I/O size with 16 workers

Тут уже измерялась производительность в IOPS для виртуальных машин на платформе VMware vSphere 5.1. При этом варьировался размер блока ввода-вывода (I/O Size) и сравнивались VMDK диски в VMFS5 и RDM-тома (нагрузка - случайное чтение):

Здесь уже на тот же самый 1% выигрывает RDM (для тестов на I/O). В тестах на MB/s ситуация в одном тесте оказалась в пользу VMFS. Масштабируемость тут уже показана не совсем линейная, при этом завал кривой начинается после размера блока в 4 Кб (единственный и по умолчанию в vSphere 5.1).

Второй тест - 60% операций чтения и 40% операций записи:

Такой рост производительности на блоке в 4 Кб объясняется просто - массив, примененный в тестировании, использует размер блока 4 Кб.

Вывод обоих тестов - виртуальные диски VMDK и RDM практически идентичны с точки зрения производительности.

Мы уже много писали про продукт номер 1 для создания отказоустойчивых хранилищ StarWind iSCSI SAN 6.0, в том числе про экономическую эффективность решения и его новые возможности. Многие знают, что у StarWind есть хорошая подборка материалов по настройке и эксплуатации данного продукта.

Сегодня мы хотим обратить ваше внимание на документ "StarWind iSCSI SAN & NAS: Multipathing", в котором детально и по шагам рассказывается о настройке механизма доступа по нескольким путям (MPIO) при использовании сервера хранилищ StarWind iSCSI SAN. В руководстве рассматривается настройка серверов на базе следующей схемы подключения:

В документе описаны способы настройки серверов как на платформе Windows Server 2008, так и Windows Server 2012.

Duncan и Frank, известные своими изысканиями в сфере механизмов отказоустойчивости (HA) и балансировки нагрузки (DRS) в виртуальной инфраструктуре VMware vSphere, опубликовали пару интересных материалов, касающихся настройки среды vCloud Director и механизма Storage DRS.

Как вы знаете, в настройках кластера хранилищ (Datastore Cluster) есть галка, которая определяет, будут ли виртуальные диски VMDK машин обязательно находиться на одном хранилище (Datastore) при миграции средствами механизма Storage DRS:

Надо отметить, что галка Keep VMDKs together by default - это не совсем простая для понимания галка. Если ее не поставить, то действовать будет обратное - диски виртуальной машины будут обязательно размещаться на разных хранилищах. Это, по заверениям блоггеров, даст больше гибкости в использовании механизма SDRS в среде vCloud Director при перемещении виртуальных машин между хранилищами, что даст больше преимуществ в динамически балансирующейся среде (особенно для "тонких" дисков). Соответственно, по умолчанию галка Keep VMDKs together by default должна быть выключена.

В прошлом году я обещал выложить оффлайн-демо продуктов VMware, которые не попали в обзор, в случае, если будет запрос на их выкладывание сюда. Запросов оказалось достаточно, поэтому продолжим эту традицию, но уже без обзора, а просто выложим файлы списком.

Собственно файлы:

• Capacity_IQ_-_Offline_Demo.zip
• Chargeback_1.5_-_Offline_Demo.zip
• ITBM_7.5_-_Financial_Mgmt_Overview_-_Offline_Demo.zip
• Private_Cloud_Cap-Mgmt-Auto-Remediation_-_Offline_Demo.zip
• Private_Cloud_Health-Change-Compliance_-_Offline_Demo.zip
• Site_Recovery_Manager_5.0_-_Offline_Demo.zip
• SoftwareDefinedDatacenter_-_OfflineDemo.zip
• SRM_4.0_-_Offline_Demo.zip
• SRM_4.0_-_Self-Playing_Demo.zip
• vCD_Infrastructure_Resiliency_-_Offline_Demo.zip
• vCenter_CapacityIQ_1.5_-_Offline_Demo.exe.zip
• vCenter_Config_Manager_for_VI_Admins_-_Offline_Demo.zip
• vCenter_Host_Profiles_-_Offline_Demo.zip
• vCenter_Linked_Mode_-_Offline_Demo.zip
• vCenter_Operations_Manager_5.0_-_Offine_Demo.zip
• vCenter_Operations_Standard_-_Offline_Demo.zip
• vCenter_Operations_Standard_Offline_Demo_v1_0-Mar_2011.zip
• vCenter_Orchestrator_-_Offline_Demo.zip
• vCloud_Director_1.0_-_Offline_Demo.zip
• vCloud_Director_1.5_New_Features.zip
• vCloud_Director_5.1_-_Offline_Demo.zip
• vCloud_Networking_and_Security_Suite_-_Offline_Demo.zip
• vCloud_Request_Manager_Offline_Demo.zip
• vCM_5.4_in_vCenter_for_Server_Admins.zip
• vCM_5.4_OS_Provisioning_-_Offline_Demo.zip
• vCM_for_vSphere_5.4.1_-_Offline_Demo.zip
• vDS_Nexus_-_Offline_Demo.zip
• vFabric_Application_Director_-_Offline_Demo.zip
• vFabric_Gemfire_HTTP_Session_Mgt_-_Offline_Demo.zip
• vFabric_GemFire_L2_Cache_-_Offline_Demo.zip
• vFabric_GemFire_Session_Mgmt_-_Offline_Demo.zip
• vFabric_Hyperic_-_Offline_Demo.zip
• vFabric_tc_Server_-_Offline_Demo.zip
• View5.1_PoolManagement_-_OfflineDemo.zip
• View_5_Persona_Mgt_-_Offline_Demo.zip
• View_5_Pool_Mgt_-_Offline_Demo.zip
• View_Administrator_4.5_-_Offline_Demo.zip
• VMware_Data_Recovery_-_Offline_Demo.zip
• VMware_Fault_Tolerance_(BlackBerry_Server)_-_Offline_Demo.zip
• VMware_Fault_Tolerance_(SAP)_-_Offline_Demo.zip
• VMware_Infrastructure_Navigator_1.1_-_OfflineDemo.zip
• VMware_vCloud_Director_Offline_Demo_v1.0.zip
• vShield_App_with_vCloud_Director_-_Offline_Demo.zip
• vShield_Edge_-_Offline_Demo.zip
• vSphere_5_Storage_Enhancements_-_Offline_Demo.zip
• vSphere_Auto_Deploy_-_Offline_Demo.zip
• vSphere_Distributed_Switch_Features_-_Offline_Demo.zip
• vSphere_Storage_Appliance_5.1_-_OfflineDemo.zip
• vSphere_Web_Client_-_Offline_Demo.zip

Вроде все, больше нет.

В конце декабря модно давать прогнозы, касающиеся развития технологий в следующем году. Сфера облачных вычислений и технологий виртуализации - не исключение. В этом посте мы постарались собрать наиболее значимые прогнозы, которые в последнее время появились на страницах различных изданий и блогов.

Итак:

• Прогноз от Savvis - в 2013 году облака будут все еще on-premise, т.е. работать в пределах инфраструктуры компании. Выиграют те сервис-провайдеры, которые смогут предоставлять гибридную модель онпремизно-офпремизных услуг. Об этом же говорит и прогноз BlueStripe - крупные компании, само собой, от частного облака в публичное никогда полностью не уйдут - критичные сервисы всегда будут в своем датацентре:

• Прогноз от Veeam Software - гипервизоры VMware и Microsoft будут сосуществовать в инфраструктурах компаний, а также средний и малый бизнес будет использовать возможности виртуализции, которые традиционно считались доступными только Enteprise-сектору.

• Прогноз VMware: 2013-год - это год software-defined storage как продолжения концепции software-defined datacenter. Об этой концепции мы уже писали в наших статьях: "Как VMware продолжает менять подход к ИТ-инфраструктуре: концепция vVOL для хранилищ виртуальных машин vSphere" и "VMware Distributed Storage и концепция vSAN для построения хранилищ VMware vSphere". Ключевая идея этой концепции - абстрагировать ресурсы хранения для виртуальной среды и раздавать их виртуальным машинам на базе политик и SLA, а не на базе томов и дисковых массивов.

• Еще один прогноз от VMware - повсеместное применение межсетевого взаимодействия в самоопеделяемых сетях SDN (software-defined networking). Об этом мы уже писали в статьях "Компания VMware приобрела Nicira за $1 260 000 000 - зачем?","Что такое и как работает технология VXLAN для создания виртуальных сетей нового поколения для виртуальных машин VMware vSphere". Действительно, темой SDN занимается сейчас не только VMware, но и, например, Oracle. Об этом мы писали в статье "Компания Oracle покупает Xsigo Systems - ответ на покупку Nicira компанией VMware".

• В том же прогнозе рассказано про HPC Cloud Computig - высокопроизводительные публичные облака. На эту тему, конечно же, мы вспомним нашу заметку "Еще одно публичное облако IaaS - Google Compute Engine". И дествительно, кому как не Гуглу таким заниматься? Но надо помнить, что на этом рынке есть еще Microsoft (вот тут) и, конечно же, первопроходец облачных сервисов - Amazon (вот тут).

• В том же прогнозе рассказывается про эволюцию виртуальных машин, которые будут приобретать новые свойства. Например, новые технологии работы с хранилищами - "Технология Virtual Flash (vFlash) для SSD-накопителей в VMware vSphere" или использование графических модулей напрямую в ВМ (см. "Платформа VGX от NVIDIA - платы с поддержкой виртуализации GPU для VDI-инфраструктуры").

• В продолжение прогнозов от VMware - про достижение максимального уровня автоматизации частых облаков. Об этом можно почитать в наших статьях "Продукт VMware vCloud Automation Center 5.1 доступен для загрузки - новые возможности" и "VMware объявила о запуске бесплатного продукта vCenter Operations Manager Foundation и изменила комплектность vCO Management Suite 5.6.". Ну это в Пендосии, а у нас, будем надеяться, что хоть кто-то поставит себе для начала vCloud Director. Потому как с восприятием облаков в России дела обстоят совсем плохо:

• Прогноз от Citrix - концепция BYOD будет мейнстримом. Такой прогноз от Citrix неудивителен, поскольку компания предоставляет средства создания инфраструктуры доступа к корпоративным приложениям с любого устройства, которое захотел пользователь. Интересно также мнение Citrix о том, что Windows-приложения уже не будут рулить как раньше - это очевидно, поскольку все мы знаем, кто захватил мобильные платформы.

Также еще несколько предсказаний вы можете почитать вот тут. Ну и интереснейшая серия прогнозов на 2013 год вот тут (я выбрал самые интересные):

• CA Technologies Cloud Predictions for 2013: Cloud Computing's Sophomore Year
• SunGard Availability Services Predictions: Why Asset Optimization Will Rule in 2013
• Symantec 2013 Virtualization and Cloud Predictions: Innovation Out of Necessity
• VMTurbo 2013 Predictions: Operational Issues in Virtualized Data Centers and Clouds To Take Center Stage
• Citrix Predictions: Four Predictions That Will Shape Mobility In 2013
• HotLink Predictions: Attack Conflicting Goals in 2013 - Agility, Diversity, IT-as-a-Service, and Cost Containment
• Quest Software: Decrease in Backup Solutions, Increase in Protection of Services - Five 2013 Predictions
• Rackspace: Five Cloud Predictions For 2013
• Veeam 2013 Predictions: Hypervisor Coexistence and Enterprise Capabilities in the SMB
• VMware Predictions for 2013: Expect Even More Change Ahead
• Dell Predictions: 2013 - The Year of Hardware and Management Software "Convergence"
• SaaS Markets Prediction: SaaS App Marketplace Poised for Explosive Growth in 2013
• FalconStor 2013 Predictions: Deduplication Proves All Data Is Not Equal
• Virtual Bridges Predictions: 2013 - The Changing Face of VDI
• CommVault 2013 Predictions: Business IT Forecast - Partly to Mostly Cloudy with an Increasing Chance of Managed Service Providers
• SolarWinds 2013 Predictions: If the Mayans are Wrong, Here's What 2013 will Hold for Virtualization
• Acronis Predictions: 2013 - The Year the Cloud Becomes Invisible
• Stratus Technologies: The Cloud is no Place for Mission-Critical Applications. Not in 2013 or the Foreseeable Future.\
• F5 Networks 2013 Predictions: Cloud Trends Include SDN and Cloud-based Solutions

Мы уже писали о том, что средствами StarWind iSCSI SAN 6.0 можно создать трехузловой отказоустойчивый кластер хранилищ для виртуальных машин VMware vSphere (+ про экономический эффект). А на днях вышел документ "StarWind iSCSI SAN & NAS: Configuring 3-node HA Shared Storage for vSphere", описывающий настройку целевой архитектуры такого кластера:

В документе подробно описаны процессы создания HA-устройств, настройка каналов синхронизации, а также необходимые конфигурации серверов VMware ESXi.

Для начала обратите внимание, что обновление вышло не для ESXi 5.1 (последней версии гипервизора), а для ESXi 5.0 - его предыдущей версии. Так что это обновление актуально только для тех, кто еще не успел переехать со старой версии платформы.

Помимо VMware ESXi 5.0 Update 2, вышел и VMware vCenter 5.0 Update 2. Новые возможности обновлений:

• Официальная поддержка работы vCenter 5.0 на Windows Server 2012.
• Официальная поддержка новых гостевых ОС: Oracle Solaris 11, Solaris 11.1, а также Mac OS X Server Lion 10.7.5.
• Поддержка сервером vCenter механизма Guest Operating System Customization для следующих гостевых ОС: Windows 8, Windows Server 2012, Ubuntu 12.04, RHEL 6.2, RHEL 6.3.
• Сервер vCenter Essentials больше не перехватывает лимит в 192 ГБ от старой модели лицензирования.
• Исправление ошибки, когда не работал таймаут SSH-сессии после выключения и включения сервиса SSH (хотя настройка сохранялась в конфиге).
• Исправление ошибки, когда в скриптовой установке не подхватывалось получение DNS-сервера хостом по DHCP, а вместо этого выставлялись ручные настройки.
• Исправление ошибки, когда при реинсталляции ESXi сохранялся лейбл локального датастора, который был задан ранее.
• Множественные багофиксы тут и тут, а также тут.

Скачать обновленные версии гипервизора ESXi 5.0 Update 2 и сервера vCenter 5.0 Update 2 можно по этой ссылке.

Для владельцев же новой версии VMware vSphere 5.1 также есть новости - вышел VMware vCenter 5.1b.

В основном этот релиз содержит множество исправлений ошибок, про которые можно прочитать вот тут. Наиболее значимые:

• Ошибки, связанные с истечением таймаутов при работе в VMware vSphere Client.
• Нельзя было залогиниться в vSphere Web Client как пользователь домена Active Directory с нестандартным UPN.

Скачать VMware vCenter 5.1.0b можно по этой ссылке.

На днях компания Microsoft обновила пару своих решений, относящихся к инфраструктуре виртуализации на базе гипервизора Hyper-V. Во-первых, была выпущена обновленная версия решения Microsoft Assessment and Planning Toolkit 8.0 (MAP), которое предназначено для проведения обследования инфратруктуры клиента на предмет возможности миграции на платформу Windows 8, размещения физических серверов в ВМ на Hyper-V (или физических серверов на платформе Windows Server 2012), возможности миграции в облако Windows Azure, а также готовности пользовательского окружения к Microsoft Office 2013.

MAP использует инструментарий Windows Management Instrumentation (WMI), Active Directory, SMS Provider и другие техники для собра информации о программном и аппаратном обеспечении серверов и рабочих станций.

Во-вторых, вышла финальная версия семейства продуктов Microsoft System Center 2012 Service Pack 1, о возможностях которого мы уже писали вот тут.

Напомним и расширим возможности основного средства управления инфраструктурой виртуализации System Center Virtual Machine Manager 2012 SP1 на платформе Hyper-V и VMware vSphere:

• Поддержка Windows Server 2012 - в качестве ОС для установки продукта и управления виртуальными машинами (консоль можно ставить и на Windows 8).
• Поддержка механизма Hyper-V network virtualization - возможность управления сетевым взаимодействием из центральной консоли на нескольких хостах Hyper-V с использованием механизма Generic Routing Encapsulation (NVGRE) для виртуализации IP-адресов виртуальных машин, что актуально для гибридных облаков предприятий.
• Поддержка виртуальных дисков VHDX - доступно создание дисков ВМ в новом формате до 64 ТБ, а также возможность конвертации из формата VHD в VHDX.
• Поддержка файловых хранилищ Server Message Block (SMB) 3.0, общие папки на основе которых можно использовать для отказоустойчивых конфигураций (SMB Transparent Failover и SMB Multichannel). Более подробная информация в этой статье.
• Интеграция с IaaS-облаком Windows Azure - теперь из консоли SC VMM можно перемещать виртуальные машины из частного облака в публичное облако Azure и управлять им уже там, из этой же консоли.
• Управление расширениями Hyper-V Extensible Switch - возможность настройки расширяемых средствами API виртуальных коммутаторов с использованием концепции "logical switch".
• Возможность резервного копирования виртуальных машин в облаке - делается это средствами Data Protection Manager 2012, который, работая напрямую с облаком Azure, может защищать виртуальные машины.
• Развертывание физических серверов Hyper-V - теперь из виртуального диска VHDX с образом ОС можно развернуть новые хост-серверы с ролью Hyper-V из SC VMM.
• Интеграция с Operations Manager - возможность получения информации о хост-серверах для приложений, балансировщиках нагрузки и ролях пользователей через OM (в дополнение к хостам, виртуальным машинам, сетевым компонентам и прочим элементам виртуальной инфраструктуры).
• Возможность создания плагинов для VMM Console.
• Многочисленные улучшения Live Migration и Live Storage Migration.
• Портал самообслуживания VMM Self-Service Portal больше не поддерживается, вместо него нужно использовать решение App Controller для организации таких порталов.

Скачать Microsoft Assessment and Planning Toolkit 8.0 можно по этой ссылке, а Microsoft System Center 2012 Service Pack 1 станет доступным для скачивания в январе 2013 года.

Недавно мы писали о том, что появилось бесплатное издание StarWind Native SAN for Hyper-V Free edition с функциями отказоустойчивости хранилищ хост-серверов Microsoft Hyper-V.

Одновременно с этим компания StarWind объявила также о том, что решение StarWind iSCSI SAN 6.0 для хранения виртуальных машин VMware vSphere также становится бесплатным (при использовании дисковых ресурсов до 128 ГБ), при этом доступны все возможности продукта для обеспечения отказоустойчивости хранилищ. Об этом подробно написано в документе "StarWind iSCSI SAN Free. The difference between free and paid editions".

Для тех, кому лень открывать документ на английском, приводим обновленное сравнение бесплатного и коммерческого изданий StarWind iSCSI SAN 6.0:

StarWind iSCSI SAN
	Free Edition - бесплатно	Коммерческие издания (в зависимости от лицензируемой емкости 1 ТБ - 512 ТБ)
Компоненты продукта
Лицензируемая емкость хранилищ	Не ограничена для одного узла и ограничение 128 ГБ для HA-конфигурации (на узел)	1 ТБ - 512 ТБ
Размер кэша	512 МБ	Не ограничен
Централизованное управление	StarWind Console	StarWind Console
Число серверов, входящее в лицензию	2	2 или 3
Число одновременных соединений по iSCSI к хранилищам	Не ограничено	Не ограничено
Число портов Ethernet	Не ограничено	Не ограничено
Число дисковых устройств	Не ограничено	Не ограничено
Техническая поддержка, включенная в лицензию	Ограниченный режим	1 год
Апгрейд на более высокое издание	Возможен без переустановки	Вы платите только разницу между изданиями
Product Features
Отказоустойчивость узлов хранилищ (Active-Active High Availability)	(128 ГБ)
Асинхронная репликация по сетям WAN
Поддержка кластеров из общих ресурсов NAS/SAN
Технология Disk Bridge (экспорт физических дисков по iSCSI)
Технология SPTI (экспорт других физических устройств по iSCSI)
Технология Image File (виртуальный диск одним файлом)
Поддержка IPSec, CHAP, ACL, iSNS
Поддержка технологий CDP / Snapshots
Поддержка Thin Provisioning
Поддержка High Speed Caching
Службы Monitoring & Notification Services
Технологии дедупликации данных
Опциональный плагин резервного копирования (Hyper-V Backup Plug-in)	$399.00 (цена за хост-сервер)	$399.00 (цена за хост-сервер)

Не так давно мы писали о покупке компанией VMware конторы DynamicOps (выпускавшей продукт Virtual Resource Manager, VRM). Эта контора была выделена из небезызвестного банка Credit Suisse и разрабатывала средства для автоматизации гибридных облаков на базе нескольких гипервизоров (что неизбежно будет в крупных организациях с приходом Hyper-V 3.0), а также средства управления сервисными архитектурами вроде Platform-as-a-Service, Database-as-a-Service и Storage-as-a-Service.

На днях компания VMware выпустила VRM под своим брендом в виде решения VMware vCloud Automation Center 5.1, которое уже доступно для скачивания.

Как видно из картинки vCloud Automation Center построен поверх инфраструктуры vCloud Director и оперирует как IaaS-инфраструктурой (на уровне виртуальных машин), так и PaaS- и SaaS-продуктами, которые доступны пользователям для запроса и использования из единой точки. То есть, vCloud Automation Center - это средство автоматизации инфраструктуры на различных уровнях для крупных предприятий.

vCloud Automation Center упрощает доступ пользователям к облачным сервисам, предлагая портал самообслуживания. Пользователь, заходя на портал, видит сервисы, к которым ему предоставлен доступ, выбирает нужный ему сервис и размещает запрос на его развертывание.

Пользователю или группе ставится в соответствие набор политик, в соответствии с которыми определяются ресурсы, на которых развертываются сервисы, время, на которое предоставляется сервис, и облако, в котором будет развернут запрошенный сервис.

В многовендорных окружениях (например, с учетом существующих Hyper-V хостов) vCAC может развертывать сервисы не только на ресурсах под управлением vSphere/vCloud Director, но и в облачных средах других производителей, публичных облаках и на физических ресурсах. В такой конфигурации он выступает в качестве брокера сервисов, который на основе политик определяет, на каких ресурсах, на каком облаке, в какой конфигурации и на какой срок будет развернут тот или иной сервис.

Сами же существующие политики vCloud Director можно отмапировать на vCloud Automation Center:

Перед тем как поступить на исполнение, пользовательская заявка проходит через процесс утверждения в соответствии с бизнес-процессом, существующим на предприятии. Последовательность действий по утверждению заявки настраивается администратором системы при помощи визуальных средств.

После развертывания сервиса, vCAC продолжает управлять жизненным циклом сервиса. Он позволяет рассчитать стоимость сервиса для пользователя, исходя из расценок для него установленных.

vCAC постоянно следит за использованием развернутых сервисов, предоставляя администратору информацию , полезную для оптимизации использования ресурсов – избыточно сконфигурированные  и неиспользуемые сервисы.

По истечении срока предоставления сервиса, vCAC автоматически предлагает пользователю либо вывести сервис из эксплуатации либо продлить срок использования.

Преимущества для бизнеса

Скачать пробную версию VMware vCloud Automation Center 5.1 можно по этой ссылке.

Как многие знают, с выходом VMware vSphere 5.1 компания VMware объявила о нескольких новых начинаниях в сфере хранения данных виртуальных машин, таких как концепция vVOL для хранилищ vSphere и сервисы распределенного хранения VMware Distributed Storage (концепция vSAN).

Кроме того, не так давно были воплощены в жизнь такие полезные службы vSphere для работы с SSD-накопителями, как SSD Monitoring (реализуется демоном smartd) и Swap to SSD (использование локальных дисков для файлов подкачки виртуальных машин). Однако функции кэширования на SSD реализованы пока совсем в базовом варианте, поэтому сегодня вам будет интересно узнать о новой технологии Virtual Flash (vFlash) для SSD-накопителей в VMware vSphere, которая была анонсирована совсем недавно.

Эта технология, находящаяся в стадии Tech Preview, направлена на дальнейшую интеграцию SSD-накопителей и других flash-устройств в инфраструктуру хранения VMware vSphere. Прежде всего, vFlash - это средство, позволяющее объединить SSD-ресурсы хост-серверов VMware ESXi в единый пул, используемый для задач кэширования, чтобы повысить быстродействие виртуальных машин. vFlash - это фреймворк, позволяющий сторонним вендорам SSD-накопителей и кэш-устройств использовать собственные алгоритмы для создания модулей обработки кэшей виртуальных машин (плагины vFlash Cache Modules). Будет реализован и собственный базовый алгоритм VMware для работы с кэшем.

Основная мысль VMware - предоставить партнерам некий API для их flash-устройств, за счет которого виртуальные машины будут "умно" использовать алгоритмы кэширования. Для этого можно будет использовать 2 подхода к кэшированию: VM-aware caching и VM-transparent caching:

VM-aware Caching (vFlash Memory)

В этом режиме обработки кэширования флэш-ресурс доступен напрямую для виртуальной машины, которая может использовать его на уровне блоков. В этом случае на уровне виртуального аппаратного обеспечения у виртуальной машины есть ресурс vFlash Memory определенного объема, который она может использовать как обычный диск в гостевой ОС. То есть, приложение или операционная система должны сами думать, как этот высокопроизводительный ресурс использовать. Можно вообще использовать его не как кэш, а как обычный диск, хотя идея, конечно же, не в этом.

VM-transparent Caching (vFlash Cache)

В этом случае виртуальная машина и ее гостевая ОС не знают, что на пути команд ввода-вывода находится прослойка в виде flash-устройств, оптимизирующих производительность за счет кэширования. В этом случае задача специализированного ПО (в том числе от партнеров) - предоставить оптимальный алгоритм кэширования. В этом случае будет доступна настройка следующих параметров кэша:

• Гарантированный объем (Reservation size)
• Выбор программного модуля-обработчика (vFlash Cache Module)
• Режим работы кэша (write-back или write-thru)
• Размер блока (настраивается в зависимости от гостевой ОС)
• Что делать с кэшем при перемещении виртуальной машины посредством vMotion (перенести вместе с ней или удалить)

При vMotion сервер vCenter будет проверять наличие необходимых ресурсов кэширования для виртуальной машины на целевом хосте ESXi. Для совместимости с технологией VMware HA, виртуальная машина должна будет иметь доступные vFlash-ресурсы на хранилищах хостов в случае сбоя (соответственно, потребуется эти ресурсы гарантировать).

В целом vFlash в VMware vSphere обещает быть очень перспективной технологией, что особенно актуально на волне роста потребления SSD-накопителей, постепенно дешевеющих и входящих в повсеместное употребление.

Компания HP обновила Firmware для своих серверов HP ProLiant, доступное для гипервизора VMware ESXi 5.0 и более поздних версий. Обновление доступно по этой ссылке.

Процесс обновления Firmware проходит из сервисной консоли серверов VMware ESXi, при этом предварительными требованиями является наличие следующих компонентов:

• HP Insight Control for vCenter 7.1.1 или выше
• Образ ESXi 5.0 от HP (Custom image) версии 5.25 или более поздней
• HP Insight WBEM Providers offline bundle версии 1.3.5 или выше (если используется не кастомный образ HP ESXi)
• HP Agentless Management offline bundle версии 9.2.5 или выше (если используется не кастомный образ HP ESXi)

Инструкция по установке проста:

• Заходим в консоль сервера ESXi, которому доступен файл с бандлом.
• Исполняем сценарий Smart Component ./CPXXXXXX.scexe, следуя указаниям установщика.

Для каких серверов подходит обновленное Firmware:

Ну и раз уж тут речь зашла об HP, добавим, что хранилища LeftHand переименованы в StoreVirtual, а операционная система San IQ стала LeftHand OS.

На видео ниже рассказано о процессе обновления продукта для создания отказоустойчивых хранилищ StarWind iSCSI SAN с версии 5.8 на версию 6.0:

В конце прошлой недели мы рассказали о документе, где приведено сравнение гипервизоров VMware vSphere, Microsoft Hyper-V и Red Hat Enterprise Virtualization (функциональность последнего там показана для бета-версии 3.1). На днях компания Red Hat объявила о выпуске окончательной версии платформы виртуализации Red Hat Enterprise Virtualization 3.1 для серверов и виртуальных ПК.

Напомним, что мы уже писали о возможностях версии 3.0, вышедшей в самом начале этого года, а вот что нового появилось в RHEV 3.1:

• Поддержка до 160 виртуальных процессоров для ВМ
• Поддержка до 2 ТБ оперативной памяти для ВМ
• Поддержка последних линеек x86-процессоров
• Live Snapshots - поддерживаются снапшоты работающих виртуальных машин
• Улучшенный SPICE-клиент для работы с виртуальными ПК - нативная поддержка USB 2.0, в том числе для виртуальных машин Linux
• Улучшенный кроссплатформенный веб-портал администрирования
• Улучшения на дэшбоарде консоли управления в части статистической информации
• Улучшения сетевого взаимодействия, включая горячее добавление/удаление виртуальных сетевых адаптеров (vNIC), поддержка bridge-less network (создание изолированных локальных сетей на хосте), зеркалирования портов (port mirroring), а также настройки MTU
• Увеличенный объем поддерживаемых хранилищ, а также поддержка NFS v4
• Технологическое превью механизма горячей миграции хранилищ ВМ Storage Live Migration
• Улучшенный портал для пользователей с возможностью определения квот ресурсов для них (Technology Preview)
• Новая политика виртуальных ПК "auto start"
• Улучшения работы через WAN-соединения
• Улучшенный Virtual Desktop Client
• Интеграция с Red Hat Storage (содержащего GlusterFS тома)
• Командный интерфейс с использованием REST API
• Пакет разработки Python SDK с использованием REST API
• Механизм Windows Driver Deployment для гостевых ОС
• Правила фильтрации через механизм Default Network Filter (nwfilter) для виртуальных машин

В принципе, весьма немало. Скачать пробную версию решения Red Hat Enterprise Virtualization 3.1 можно по этой ссылке. Документ с полным описанием новых возможностей RHEV 3.1 доступен тут.

Мы уже писали о некоторых функциях утилиты esxcli в VMware vSphere, которая работает с различными пространствами имен, такими как network, storage, hardware и прочими. Сегодня мы хотим остановиться на новых функциях по управлению устройствами ввода-вывода I/O Device Management (IODM), пространство имен для которых появилось в VMware vSphere 5.1. Цель этих новых инструментов - дать администратору инструменты для понимания уровня, на котором происходят проблемы с хранилищем в сети SAN (см. тут).

Это новое пространство имен выглядит вот так:

esxcli storage san

Например, мы хотим сделать Reset для FC-адаптера:

esxcli storage san fc reset -A vmhba3

А потом посмотреть его лог, который включает в себя информацию о таких событиях, как разрыв соединения:

esxcli storage san fc events get

Можно собрать статистику по iscsi-адаптеру командой:

esxcli storage san iscsi stats get

Кроме того, в VMware vSphere 5.1 появились функции мониторинга твердотельных накопителей - SSD Monitoring, реализуемые метриками, которые собирает каждые полчаса демон S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology). Находятся стандартные плагины в /usr/lib/VMware/smart_plugins (кстати, вендоры дисковых устройств могут добавлять туда свои плагины вместо имеющихся generic-плагинов). Надо также отметить, что эти метрики не передаются в vCenter и доступны только через esxcli.

Посмотреть статистики SSD-дисков можно командой:

esxcli storage core device smart get -d naa.xxxxxx

Жирным выделены метрики, которые могут оказаться полезными. Параметр Reallocated Sector Count не должен сильно увеличиваться со временем для исправных дисков. Когда дисковая подсистема получает ошибку read/write/verification для сектора, она перемещает его данные в специально зарезервированную область (spare area), а данный счетчик увеличивается.

Media Wearout Indicator - это уровень "жизни" вашего SSD-диска (для новых дисков он должен отображаться как 100). По мере прохождения циклов перезаписи диск "изнашивается" и данный счетчик уменьшается, соответственно, когда он перейдет в значение 0 - его жизнь формально закончится, исходя из рассчитанного для него ресурса. Кстати, этот счетчик может временно уменьшаться при интенсивных нагрузках диска, а потом восстанавливаться со временем, если средняя нагрузка на диск снизилась.

Не так давно мы писали о том, что компания StarWind Software объявила сразу о трех релизах, одним из которых был выпуск новой версии решения для создания отказоустойчивых хранилищ под платформу Hyper-V - StarWind Native SAN for Hyper-V 6.0.

В этой статье мы расскажем о новых возможностях, которое приобрело это средство номер 1 для создания iSCSI-хранилищ под виртуализацию Hyper-V.

Итак, что нового:

• Много улучшений High Availability. Во-первых, улучшился уровень юзабилити - теперь интерфейсы выглядят проще и работают быстрее. Многие операции снабжены мастерами. Во-вторых, улучшился движок HA - теперь можно производить операции add, remove и switch для HA-узла без вывода его в режим "Offline".
• Новые функции HA-устройств. Теперь в качестве HA-устройств могут быть использованы такие девайсы как deduplicated, thin-provisioned IBV или DiskBridge. Это означает, что теперь доступна функциональность дедупликации, thin provisioning, снапшоты и прочее для HA-устройств.
• Улучшения дедупликации:
• Asynchronous replication of deduplicated data - теперь данные для репликации по медленным каналам (WAN) могут передаваться асинхронно, что позволяет использовать решение в DR-сценариях. Кроме того, теперь любой тип устройства может быть целевым для репликации.
• Deletion of unused data - неиспользуемые блоки, появляющиеся на дедуплицируемом хранилище, записываются актуальными данными, что позволяет использовать пространство более эффективно.
• Decreased memory usage - в этой версии StarWind Native SAN на 30% снижены требования к памяти сервера. Теперь при использовании блоков 4 KB только 2 МБ оперативной памяти требуется на 1 ГБ хранимых данных.
• Полная поддержка Windows Server 2012.

Скачать StarWind Native SAN for Hyper-V 6.0 можно по этой ссылке. И напоминаем, что у этого решения есть полнофункциональная бесплатная версия.

На днях сообщество разработчиков Xen объявило о выпуске обновленной версии платформы Xen Cloud Platform 1.6 (XCP), которая предназначена для управления облачной инфраструктурой на базе гипервизора Xen (в каком-то смысле это аналог коммерческого XenServer). Напомним, что о решении Xen Cloud Platform версии 1.1 мы уже писали годом ранее, а в стадии беты версия 1.6 уже находилась с октября этого года.

XCP построена на базе свободного гипервизора Xen (в новой версии - 4.1.3), к которому прилагаются различные возможности для построения облачных инфраструктур посредством Xen API toolstack. Платформа XCP распространяется под лицензией GNU General Public License (GPL2).

Новые возможности Xen Cloud Platform 1.6:

• Технология Storage XenMotion, позволяющая проводить миграцию работающих виртуальных машин на другой хост и хранилище, при этом хосты могут быть в разных пулах и не иметь общего хранилища, т.е. горячая миграция ВМ доступна между локальными дисками хост-серверов.
• Технология Live Virtual Disk Image migration, предоставляющая возможности миграции ВМ без ее выключения.
• Улучшения сетевого взаимодействия:
  • Поддержка Link Aggregation Control Protocol (LACP)
  • Технология Source Load Balancing (SLB)
  • Улучшения Multi-tenancy
  • Улучшения масштабируемости сетей VLAN
  • Технология отката настроек Emergency Network Reset
  • Поддержка IPv6 в гостевых ОС
• Упрощенный механизм для изменения vCPU для Control Domain ("dom0")
• Обновленный коммутатор Open vSwitch до версии 1.4.2 с улучшениями стабильности и производительности
• Поддержка технологии Integrated StorageLink (iSL) для массивов EMC VNX
• Технлогия GPU Pass-through (проброс видеокарт в гостевую ОС): поддержка до 4 GPU на хост-сервер
• Улучшения для интеграции со сторонними решениями: байндинги для XenAPI для языка C, расширения Workload Balancing (WLB) и общие улучшения
• Поддержка техники hypervisor monitoring (vhostmd), позволяющей приложениям SAP работать в виртуальной машине XCP

Новые поддерживаемые гостевые ОС в XCP 1.6:

• Ubuntu 12.04
• CentOS 5.7, 1.5, 6.1, 6.2
• Red Hat Enterprise Linux 5.7, 6.1, 6.2
• Oracle Enterprise Linux 5.7, 6.1, 6.2

Развитие функциональности платформы XCP можно проследить по таблице ниже:

В целом с версии 1.1 платформа XCP 1.6 получила немало новых функций (релизная версия 1.5 так и не была выпущена), поэтому некоторые сервис-провайдеры и крупные организации могут уже начать задумываться о построении инфраструктуры на базе этого решения. Более подробно о новой версии Xen Cloud Platform 1.6 рассказано тут, а по этой ссылке ее можно скачать.

Некоторые из вас, вероятно, видели документ, называющийся "VMFS File Locking and Its Impact in VMware View 5.1", доступный у нас вот тут. Он вкратце рассказывает о нововведении в VMware View 5.1 - теперь для пулов связанных клонов (Linked Clones) можно использовать кластеры до 32-х хостов, а не 8 как раньше. Но работает это только для тех окружений, где реплика базового образа размещена на NFS-хранилище, для VMFS же хранилищ ограничение осталось тем же самым - кластер из максимум 8 хостов. Давайте разбираться, почему это так.

Во-первых, посмотрим как выглядит классическая структура связанных клонов в инсталляции VMware View:

В пуле связанных клонов, который мы можем построить с помощью VMware View Composer, находится создаваемый и настраиваемый базовый образ (может быть со снапшотом), из которого создается реплика этой ВМ (Replica), на базе которой из дельта-дисков строятся уже конечные десктопы пользователей. При этом данные реплики используются одновременно всеми связанными клонами, которые располагаются на хост-серверах ESXi кластера.

Теперь напомним, что мы уже рассматривали типы блокировок (локов) в кластерной файловой системе VMFS. Однако там рассмотрены не все блокировки, которые могут быть применены к файлам виртуальных дисков. Мы рассматривали только эксклюзивную блокировку (Exclusive Lock), когда только один хост может изменять VMDK-файл, а все остальные хосты не могут даже читать его:

Такие блокировки используются в традиционном окружении инфраструктуры виртуализации для серверной нагрузки в виртуальных машинах. Очевидно, что такие блокировки не подходят для доступа к данным файла виртуального диска реплики VMware View.

Поэтому есть и другие типы блокировок. Во-первых, Read-Only Lock (в этом режиме все хосты могут читать один VMDK, но не могут менять его):

Во-вторых, Multi-Writer Lock:

В режиме такой блокировки сразу несколько хостов могут получить доступ к VMDK-файлу на общем хранилище VMFS в режиме Read/Write. При использовании инфраструктуры связанных клонов на хранилище применяются локи типа Read-Only Lock и Multi-Writer Lock, что требует одновременного доступа нескольких хостов ESXi к одному файлу. Естественно, где-то в локе должны храниться данные о том, какие хосты используют его.

А теперь посмотрим на внутренности лока. Они как раз и содержат все UID (User ID) хостов, которые работают с VMDK-файлом, в структуре "lock holders". Надо отметить, что для работы автоматической процедуры обновления лока необходимо, чтобы его размер был равен одному сектору или 512 байтам. А в этот объем помещается только 8 этих самых UID'ов, а девятый уже не влезает:

Напомню, что мы говорим про диск реплики, который необходим сразу всем хостам кластера с виртуальными ПК этого пула. Поэтому, как и раньше, в VMware View 5.1 нельзя использовать для реплики, размещенной на томе VMFS, кластер из более чем восьми хост-серверов VMware ESXi.

Однако можно поместить реплику на том NFS. По умолчанию протокол NFS не поддерживает file locking, однако поддерживает механизм Network Lock Manager (NLM), который использует схему блокировок "advisory locking":

В этой схеме клиенты файла NFS могут координировать между собой совместный доступ к файлу (в нашем случае - VMDK). При этом никакого лимита на 8 хостов в этом механизме нет. Однако раньше в VMware View не позволялось использовать более 8 хостов в кластере для пула связанных клонов.

Теперь это сделать можно и, во многих случаях, даже нужно, выбрав NFS-хранилище для пула Linked Clone:

Таким вот нехитрым образом NFS побеждает VMFS :)

На прошлой неделе мы писали о том, что компания StarWind Software объявила сразу о трех релизах, одним из которых был выпуск новой версии решения для создания отказоустойчивых хранилищ под платформу Hyper-V - StarWind Native SAN for Hyper-V 6.0.

В скором времени мы расскажем о новых возможностях продукта поподробнее (документ What's New), а пока приглашаем на вебинар "Overview of StarWind Native SAN for Hyper-V 6.0", который состоится завтра 28 ноября в 18-00 по московскому времени:

Там собственно и будут раскрыты все новые возможности этого решения, у которого есть еще и полнофункциональная версия StarWind Native SAN for Hyper-V Free Edition, ограниченная лишь объемом хранилища (128 ГБ).

Зарегистрироваться на вебинар.

Многие знают компанию StarWind как производителя средства номер 1 для создания отказоустойчивых хранилищ StarWind iSCSI SAN под виртуальные машины VMware vSphere. Не так давно вышла обновленная версия StarWind iSCSI SAN 6.0 этого решения. Но, как известно, StarWind предлагает еще и отказоустойчивое решение для серверов Hyper-V.

15 ноября компания StarWind сделала 3 важных анонса, которые вам будут, безусловно, интересны:

• Во-первых, вышла новая версия продукта под гипервизор Microsoft Hyper-V: StarWind Native SAN 6.0 (документ с описанием новых возможностей вот тут)
• Во-вторых, вышла финальная версия решения для резервного копирования виртуальных машин на VMware vSphere, поставляемого в виде плагина - VMware Backup Plug-in.  Теперь продукт полностью поддерживает новую платформу VMware vSphere 5.1.
• В-третьих, появилось бесплатное издание StarWind Native SAN for Hyper-V Free edition с функциями отказоустойчивости хранилищ.

Поскольку из этих новостей самая интересная - третья, то мы расскажем о бесплатном продукте StarWind Native SAN for Hyper-V Free edition. Он позволяет построить небольшой, но отказоустойчивый кластер хранилищ из двух серверов Microsoft Hyper-V на основе протокола iSCSI, без необходимости вложений во что бы то ни было - серверы под СХД или лицензии. Можно взять 2 обычных хост-сервера Hyper-V и забацать кластер.

Давайте взглянем на отличие бесплатного продукта от его платной версии:

StarWind Native SAN for Hyper-V
	Free Edition - бесплатно	Small Business	Midsize Business	Enterprises
Компоненты продукта
Лицензируемая емкость хранилищ	Не ограничена (HA-хранилище ограничено размером 128 ГБ)	1 ТБ / 2 ТБ (HA)	4 ТБ / 8 ТБ (HA)	16 ТБ/Не ограничено (HA)
Централизованное управление	StarWind Console	StarWind Console	StarWind Console	StarWind Console
Число серверов, входящее в лицензию	2	2 или 3	2 или 3	2 или 3
Число одновременных соединений по iSCSI к хранилищам	Не ограничено	Не ограничено	Не ограничено	Не ограничено
Число портов Ethernet	Не ограничено	Не ограничено	Не ограничено	Не ограничено
Число дисковых устройств	Не ограничено	Не ограничено	Не ограничено	Не ограничено
Техническая поддержка, включенная в лицензию	Ограниченный режим	1 год	1 год	1 год
Апгрейд на более высокое издание	Возможен без переустановки	Вы платите только разницу между изданиями	Вы платите только разницу между изданиями	Вы платите только разницу между изданиями
Product Features
Отказоустойчивость узлов хранилищ (Active-Active High Availability)	(128 ГБ)
Асинхронная репликация по сетям WAN
Поддержка кластеров из общих ресурсов NAS/SAN
Технология Disk Bridge (экспорт физических дисков по iSCSI)
Технология SPTI (экспорт других физических устройств по iSCSI)
Технология Image File (виртуальный диск одним файлом)
Поддержка IPSec, CHAP, ACL, iSNS
Поддержка технологий CDP / Snapshots
Поддержка Thin Provisioning
Поддержка High Speed Caching
Службы Monitoring & Notification Services
Технологии дедупликации данных
Опциональный плагин резервного копирования (Hyper-V Backup Plug-in)	$399.00 (цена за хост-сервер)	$399.00 (цена за хост-сервер)	$399.00 (цена за хост-сервер)	$399.00 (цена за хост-сервер)

Из таблицы видно, что бесплатная версия StarWind Native SAN for Hyper-V Free edition практически ничем не отличается от платной, кроме ограничения на размер отказоустойчивого хранилища в 128 ГБ. Полное сравнение платного и бесплатного изданий StarWind Native SAN for Hyper-V доступно по этой ссылке.

Тем, у кого диски машин используют меньше места, чем 128 ГБ, настоятельно рекомендуется скачать и протестировать продукт.

Мы уже не раз затрагивали тему vswp-файлов виртуальных машин (файлы подкачки), которые используются для организации swap-пространства гипервизором VMware ESXi. Эти файлы выполняют роль последнего эшелона среди техник оптимизации памяти в условиях недостатка ресурсов на хосте. Напомним, что в гипервизоре VMware ESXi есть такие техники как Transparent Page Sharing, Memory Ballooning, a также Memory Compression, которые позволяют разбираться с ситуациями нехватки памяти, необходимой виртуальным машинам.

Напомним также, что первым эшелоном оптимизации памяти является техника Memory Ballooning. Она работает за счет использования драйвера vmmemctl.sys (для Windows), поставляемого вместе с VMware Tools. Он позволяет "надуть" шар внутри гостевой ОС (balloon), который захватывает физическую память, выделенную этой ОС (если ее много), и отдает ее другим гостевым операционным системам, которые в ней нуждаются. Этот balloon не позволяет гостевой ОС производить работу приложений с данной областью памяти, поэтому если им потребуется дополнительная память - она будет уходить в гостевой своп. Это более правильный подход, чем свопировать гостевую ОС в файл подкачки vswp на томе VMFS, поскольку операционная система сама лучше разбирается, что и когда ей класть и доставать из свопа (соответственно, быстродействие выше).

Однако, когда памяти у всех виртуальных машин совсем мало или отдельной ВМ ее требуется больше, чем сконфигурировано, а также происходит постоянное обращение к памяти (особенно, если в гостевых ОС нет VMware Tools), гипервизор начинает использовать vswp-файл подкачки, который по умолчанию находится в папке с виртуальной машиной. Мы уже писали о том, что в целях повышения быстродействия можно положить vswp-файлы виртуальных машин на локальные SSD-хранилища серверов ESXi, а также о том, как удалять мусорные файлы vswp.

Ниже мы приведем 8 фактов о swap-файлах виртуальных машин, которые основаны на вот этой заметке Фрэнка Деннемана:

1. Хранение vswp-файлов на локальных дисках сервера ESXi (в том числе Swap to Host Cache) увеличивает время vMotion. Это очевидно, так как приходится копировать vswp-файл в директорию ВМ (или другую настроенную директорию), чтобы его видел целевой хост.

2. С точки зрения безопасности: vswp-файл не чистится перед созданием. То есть там лежат не нули, а предыдущие данные блоков. Напоминаем, что размер файла подкачки равен размеру сконфигурированной памяти ВМ (если не настроен Reservation). Если же у машины есть Reservation, то размер vswp-файла определяется по формуле:

Configured memory – memory reservation = size swap file

То есть, если в настройках памяти машины ей выделено 4 ГБ, а Reservation настроен в 1 ГБ, то vswp-файл будет составлять 3 ГБ.

3. Как происходит копирование vswp-файла при vMotion? Сначала создается новый vswp-файл на целевом хосте, а потом копируются только swapped out страницы с исходного в целевой vswp-файл.

4. Что происходит при разнице в конфигурации размещения vswp-файлов в кластере и для отдельных хостов? Напомним, что в настройках кластера VMware vSphere есть 2 опции хранения vswp-файлов: в папке с ВМ (по умолчанию) и в директории, которая указана в настройках хоста:

Если на одном хосте настроена отдельная директория для vswp, а на другом нет (то есть используется папка ВМ), то при vMotion такой виртуальной машины vswp-файл будет скопирован (в папку с ВМ), несмотря на то, что целевой хост видит эту директорию на исходном.

5. Обработка файлов подкачки при нехватке места. Если в указанной директории не хватает места для свопа ВМ, то VMkernel пытается создать vswp-файл в папке с ВМ. Если и это не удается, то виртуальная машина не включается с сообщением об ошибке.

6. vswp-файл лучше не помещать на реплицируемое хранилище. Это связано с тем, что используемые страницы памяти, находящиеся в двух синхронизируемых файлах, будут постоянно реплицироваться, что может вызывать снижение производительности репликации, особенно если она синхронная и особенно при vMotion в недефолтной конфигурации (когда происходит активное копирование страниц и их репликация):

7. Если вы используете снапшоты на уровне хранилищ (Datastore или LUN), то лучше хранить vswp-файлы отдельно от этих хранилищ - так как в эти снапшоты попадает много ненужного, содержащегося в своп-файлах.

8. Нужно ли класть vswp-файлы на хранилища, которые развернуты на базе thin provisioned datastore (на уровне LUN)? Ответ на этот вопрос зависит от того, как вы мониторите свободное место на тонких лунах и устройствах своего дискового массива. При создании vswp-файла VMkernel определяет его размер и возможность его создания на уровне хоста ESXi, а не на уровне устройства дискового массива. Поэтому если vswp-файл активно начнет использоваться, а вы этого не заметите при неправильной конфигурации и отсутствии мониторинга тонких томов - то могут возникнуть проблемы с их переполнением, что приведет к сбоям в работе ВМ.

Компания VMware недавно запустила новый проект в рамках своего направления по обучению пользователей - vmwarelearning.com.

В качестве обучающих материалов доступны видеозаписи о следующих продуктах VMware:

• Site Recovery Manager
• vCenter Operations Manager
• vCloud
• vFabric/Spring
• vSphere
• vSphere Storage Appliance

Пока на сайте всего 50 бесплатных обучающих видеозаписей, но их количество будет постоянно пополняться. Сайт является хорошим дополнением к VMware Mobile Knowledge Portal. Планируются также выпуски не только на английском языке, однако русский в ближайшие планы VMware, по-видимому, не входит.